The invention relates generally to software applications and, more particularly, to methods and apparatus for controlling execution of a software component that resides within an isolated execution unit.
In many software applications, there is a need for isolated execution units. An isolated execution unit generally does not share its states with other software modules which are not a part of the isolated execution unit. Conventionally, a software module that does not reside within an isolated execution unit cannot communicate with other software modules that do reside in the isolated execution unit. For example, an isolated execution unit does not share memory with another software module that does not reside within the isolated execution unit. Since isolated execution units do not share states, a particular isolated execution unit is protected from an erroneous behavior running in another isolated execution unit. Examples of isolated execution units include a “process” in a Unix operating system or a Logical Virtual Machine on a Java platform.
Each isolated execution unit may also create one or more internal software components. For example, a isolated execution unit may take the form of a browser application that spawns a software component in the form of an applet. Several different software component models have been proposed, including Java applet, Java Xlet and Java servlet. Those software component models typically have unique APIs (Application Programming Interfaces) that are different from each other.
There are some cases where it is better to locate and execute these software components in different isolated execution units than the one that creates them in order to isolate erroneous behavior. For example, a web browser spawns an isolated execution unit; it instantiates a new applet in it; then the web browser starts the execution of the applet. However, there are several difficulties to practicing this scheme. FIG. 1 is a diagrammatic representation of a typical isolated execution unit setup. As shown, a isolated execution unit 102 includes an internal software component 104. The isolated execution unit has API 108, and the software component 104 has API 110 that may differ from the isolated execution unit's API 108. A parent program 106 communicates with the isolated execution unit 102 through the API 108 of the isolated execution unit 102. However, the parent program 106 cannot communicate with the software component 104 since the software component's API 110 is not accessible by the parent program 106. That is, the software component's API 110 is “isolated” from the parent program 106.
Since the parent program 106 cannot communicate with the software component, the parent program 106 cannot access API 110 of the software component 104. The parent program may need to access the API 110 to control the software component for any number of reasons. In one example, the isolated execution unit 102 represents a web browser and the software component 104 is an applet. If the applet 104 misbehaves, it is desirable to shut down the applet. However, in this setup the applet can only be terminated by shutting down the entire browser 102. That is, the browser 102 is needlessly shut down. Of course, shutting down the browser is typically very undesirable. In another example, the parent program cannot initialize the state of the isolated execution unit before execution of the software component to a desired state. For example, this initialization may include assigning initial values to execution environment variables.
A conventional technique for solving this problem is to provide multiple APIs within the isolated execution unit for each kind of software component within the isolated execution unit. FIG. 2 is a diagrammatic representation of a communication mechanism, where an isolated execution unit 202 has been modified to expose an internal component's API. As shown, the isolated execution unit 202 includes API 208 for software component 204. A parent program 206 may then communicate with software component 204 through the exposed API 208.
This approach has several associated disadvantages. Since an API must be created for each software component, a significant number of API's may have to be created. Additionally, modification of an isolated execution unit is not desirable. One reason is that modification of the isolated execution unit can be rather complex and time consuming. Also, modification of the isolated execution unit for each software component cancels out the advantages of using software components in the first place, e.g., the ability to simply use software components “as is” without modification.
Accordingly, there is a need for improved mechanisms for controlling or monitoring execution of a software component that is associated with an isolated execution unit.